Cloudflare Zero Trust の WARP をインストールした時の接続先と内部通信を整理した

今回は Cloudflare Zero Trust の WARP の通信アーキテクチャについて整理したいと思います。
WARP インストールの際のトラブルシューティングやファイアウォールの穴あけなどの際、どのタイミングで何の通信が発生しているか把握しておきたい時があるかと思います。

アカウント開設方法や WARP インストール等について確認されたい方はこちらをご参照ください：

WARP の５つのモード

WARP には利用用途に合わせて５つのモードを選択することができます。
モードによって、WARP が処理する範囲が大きく変わってくるのですが、それぞれのモードについて簡単にまとめました。

WARPモード	説明
Gateway with WARP	DNSトラフィック、IPトラフィックともにCloudflareへ送信
Gateway with DoH	DNSトラフィックのみCloudflareへ送信
Secure Web Gateway without DNS Filtering	WARPトンネル、デバイスポスチャの機能のみ利用。IPトラフィックのみをCloudflareへ送信
Device Information Only	DNSトラフィック、IPトラフィックともにOSの設定に従う。デバイスポスチャの機能を使った通信制御のみ適用
Proxy mode	HTTPプロキシまたはSOCKS5プロキシとして利用。HTTPポリシー、ブラウザアイソレーション、IDベースポリシー、AVスキャン、DLPの機能が利用可能

基本的に利用するモードは、最も機能が豊富に使えセキュリティ効果も高い Gateway with WARP になるかと思います。
この記事では Gateway with WARP での動作について詳細を確認していきます。

WARP（端末）が通信する先

まずこちらのアーキテクチャ図を見て下さい。

参照元:

アーキテクチャ図をインプットした上で、詳しく見ていきます。
公式のドキュメントにも記載されていますが、WARP が通信する先を以下にまとめていきます。

クライアントオーケストレーション API エンドポイント

ユーザーの登録、WARP のプロファイル更新、デバイスポスチャチェックを行うためのエンドポイント

	説明
通信プロトコル	HTTPS 443
通信先	IPv4 - 162.159.137.105 and 162.159.138.105、IPv6 - 2606:4700:7::a29f:8969 and 2606:4700:7::a29f:8a69
補足	アーキテクチャ図の上部の通信 Device orchestration の Cloudflare 側の入り口にあたるところになります

DoH(Domain Over HTTPS) エンドポイント（DoH IP）

通信先のドメインの名前解決を行うための DNS リゾルバ。DNS 通信は HTTPS 通信で暗号化される

	説明
通信プロトコル	HTTPS 443
通信先	IPv4 - 162.159.36.1 and 162.159.46.1、IPv6 - 2606:4700:4700::1111 and 2606:4700:4700::1001
補足	アーキテクチャ図の中部の通信 DoH の Cloudflare 側の入り口にあたるところになります

WARP エンドポイント（WARP Ingress IP）

WARP が Cloudflare との Wireguard トンネルを構築する先となるエンドポイント

	説明
通信プロトコル	UDP 2408, 500, 1701, 4500
通信先	IPv4 - 162.159.193.0/24、IPv6 - 2606:4700:100::/48
補足	アーキテクチャ図の下部の通信 Wireguard の Cloudflare 側の入り口にあたるところになります

クライアント認証エンドポイント

WARP レジストレーション時のクライアント認証の最初にアクセスする先となるエンドポイント

	説明
通信プロトコル	HTTPS 443
通信先	.cloudflareaccess.com
補足	アーキテクチャ図には記載ありませんが、 Device orchestration と同じ扱いとなります

その他

これらの通信先は、基本的に公衆Wi-Fiやリモートワーク先（自宅等）で利用される通信となるので、通信にFirewall の制御の対象と考えなくても良いかと思います。

• キャプティブポータル

キャプティブポータル環境下どうかを判定するため、インターネットへの疎通確認を行うエンドポイント
以下のドメインと通信チェックが行われるときがあります。

cloudflareportal.com、cloudflareok.com、cloudflarecp.com

• コネクティビティチェック

インターネットの接続性があるかどうかを確認を行うためのエンドポイント

Wireguard トンネルの外側の通信で行われます。
engage.cloudflareclient.com

Wireguard トンネルの内側の通信で行われます。
connectivity.cloudflareclient.com

WARP（端末）の内部処理について

WARP（端末）の内部処理については Cloudflare のドキュメントでは以下のようになると書かれています。

DNSトラフィック

DNS 通信は全て以下のループバックインターフェースで処理されます。
Local Domain Fallback に設定されたドメインの名前解決は、指定したローカルのDNSリゾルバに運ばれ、それ以外は DoH コネクションを通して Cloudflare に運ばれます。

• IPv4: 127.0.2.2 and 127.0.2.3
• IPv6:
  • macOS and Linux: fd01:db8:1111::2 and fd01:db8:1111::3
  • Windows: ::ffff:127.0.2.2

IPトラフィック

以下のような仮想インターフェイスが作成され、IPベースのトラフィックはクライアントオーケストレーション API との通信または Split Tunnel に設定されたもの以外は全てこのインターフェイスで処理されます。

• IPv4: 171.16.0.2

クライアントオーケストレーション API との通信または Split Tunnel で設定した宛先との通信はデフォルトのインターフェイスで処理されます。

• WARP端末のデフォルトのインターフェイス

検証

それでは実際に通信をキャプチャして Wireshark を使ってパケットを分析してみます。

最初にインターフェイスの状態を確認しておきます。

Wireless LAN adapter Wi-Fi:

   接続固有の DNS サフィックス . . . . .: flets-west.jp
   説明. . . . . . . . . . . . . . . . .: Intel(R) Wi-Fi 6 AX201 160MHz
   IPv6 アドレス . . . . . . . . . . . .: ****:****:****:****:****:****:****:****(優先)
   一時 IPv6 アドレス. . . . . . . . . .: ****:****:****:****:****:****:****:****(優先)
   リンクローカル IPv6 アドレス. . . . .: ****::****:****:****:****%6(優先)
   IPv4 アドレス . . . . . . . . . . . .: 192.168.10.102(優先)
   サブネット マスク . . . . . . . . . .: 255.255.255.0
   デフォルト ゲートウェイ . . . . . . .: ****::****:****:****:****%6
                                          192.168.10.1
   DNS サーバー. . . . . . . . . . . . .: 192.168.10.1
   NetBIOS over TCP/IP . . . . . . . . .: 有効

• 192.168.10.102 -> WARP をインストールする端末
• 192.168.10.1 -> ホームルーター・DNSリゾルバ

Cloudflare レジストレーションの通信

それでは、まず WARP をインストールした直後の Cloudflare のレジストレーションの通信から見ていきます。

Cloudflare レジストレーションのための端末での操作

レジストレーションを開始します。WARP のレジストレーションは IdP を連携するように設定してあります。
WARP の設定画面を開いて Cloudflare にログイン をクリックし、認証を進めます。

ブラウザが開き、認証方法を選び、IdPなどの認証を進めます。

レジストレーション時のデフォルトインターフェイスのキャプチャ画面

その時のキャプチャをとって、パケットを確認していきます。

ホームルーターに向けて<cloudflare-team-name>.cloudflareaccess.comのDNSクエリが確認できます。

この時は UDP 53 のクエリになっています。

ブラウザで認証を要求する画面が表示されたタイミングで TCP3ウェイハンドシェイクや TLS 通信が行われています。（HTTPS 通信と予測されます。）

IdP は Microsoft Entra ID (旧Azure AD)と連携させているので、別途 Entra ID の認証ポイントとの通信も発生します。

WARPをON時とその後の通信

続いて、WARPをON時とその後の通信について確認していきます。

WARPをONにするための端末での操作

これでレジストレーションが完了したので、次に WARP をONにしてみます。

WARPをONにした時のデフォルトインターフェイスのキャプチャ画面

WARP がONになったタイミングのデフォルトインターフェイスのキャプチャを見てみると、DoH エンドポイントとの通信が確認できます。

IPv4、IPv6ともにTCP 443で接続が確認できます。HTTPS のセッションをデフォルトインターフェイスで確立しているのが分かります。この後のDNS通信はループバックインターフェースでDNSクエリが確認できるようになるので、後ほど見てみます。

またこのDoHエンドポイント自体の名前解決は行われていないようです。ソフトウェアである WARP がIPアドレスで直接通信しにいっているためと思われます。

さらにクライアントオーケストレーション API エンドポイントとの接続も確認することができます。
こちらの通信もDNSによる名前解決は発生せずに WARP がIPアドレスで直接通信しにいく動きとなっていました。

次に WARP がWireguardトンネルを構築するための通信を確認することができます。
2606:4700:100::/48 の範囲である 2606:4700:100::a29f:c108 と接続しています。
またUDP Port 2408と接続していることが確認できます。

WARPをONにした時のループバックインターフェースのキャプチャ画面

続いてループバックインターフェースでキャプチャしたパケットを確認してみます。
DNSクエリはループバックインターフェースで確認できるようになりました。

connectivity.cloudflareclient.com の名前解決も行われていることが確認できます。

WARPをONにした直後の ipconfig /all

先ほど、Wireguard のトンネル構築のやりとりが行われたタイミングで仮想インターフェースが作成されています。
```ipconfig /all````で再度インターフェースの状態を確認してみます。

不明なアダプター CloudflareWARP:

   接続固有の DNS サフィックス . . . . .:
   説明. . . . . . . . . . . . . . . . .: Cloudflare WARP Interface Tunnel
   物理アドレス. . . . . . . . . . . . .:
   DHCP 有効 . . . . . . . . . . . . . .: いいえ
   自動構成有効. . . . . . . . . . . . .: はい
   IPv6 アドレス . . . . . . . . . . . .: 2606:4700:110:****:****:****:****:****(優先)
   リンクローカル IPv6 アドレス. . . . .: fe80::****:****:****:****%19(優先)
   IPv4 アドレス . . . . . . . . . . . .: 172.16.0.2(優先)
   サブネット マスク . . . . . . . . . .: 255.255.255.255
   デフォルト ゲートウェイ . . . . . . .:
   DNS サーバー. . . . . . . . . . . . .: 127.0.2.2
                                          127.0.2.3
   NetBIOS over TCP/IP . . . . . . . . .: 有効

Wireless LAN adapter Wi-Fi:

   接続固有の DNS サフィックス . . . . .: flets-west.jp
   説明. . . . . . . . . . . . . . . . .: Intel(R) Wi-Fi 6 AX201 160MHz
   IPv6 アドレス . . . . . . . . . . . .: ****:****:****:****:****:****:****:****(優先)
   一時 IPv6 アドレス. . . . . . . . . .: ****:****:****:****:****:****:****:****(優先)
   リンクローカル IPv6 アドレス. . . . .: fe80::****:****:****:****%6(優先)
   IPv4 アドレス . . . . . . . . . . . .: 192.168.10.102(優先)
   サブネット マスク . . . . . . . . . .: 255.255.255.0
   デフォルト ゲートウェイ . . . . . . .: ****::****:****:****:****%6
                                          192.168.10.1
   DNS サーバー. . . . . . . . . . . . .: ::ffff:127.0.2.2
                                          127.0.2.2
                                          127.0.2.3
   NetBIOS over TCP/IP . . . . . . . . .: 有効

Cloudflare WARP というインターフェイスが作成され、デフォルトインターフェイスのDNSサーバーも変更されました。

WARPをONにした直後の仮想インターフェイスのキャプチャ画面

Cloudflare WARP のインターフェイスのパケットキャプチャも取得し、確認してみます。

DoHで名前解決された通信は、Cloudflare WARP インターフェイスに向けて投げられていることが確認できます。
先程のconnectivity.cloudflareclient.comの名前解決後の通信もここで行われていることが確認できます。

まとめ

通信シーケンスや接続先を整理しておくことで、トラブルシューティングの際や、ファイアウォールの穴あけに役立つかと思い、実際にパケットの流れを追いながら確認してみました。
どなたかの一助になればと思います。